home *** CD-ROM | disk | FTP | other *** search
/ Aminet 45 / Aminet 45 (2001)(GTI - Schatztruhe)[!][Oct 2001].iso / Aminet / game / role / ldmud-3.2-bin.lha / mud / doc / concepts / intermud < prev    next >
Text File  |  2001-07-14  |  7KB  |  198 lines
  1. CONCEPT
  2.     intermud
  3.  
  4. DESCRIPTION
  5.     There are several intermud protocols which define how (players on)
  6.     different muds can communicate with each other. The protocols are
  7.     in general not muddriver or mudlib dependant, though the number of
  8.     implementations is limited.
  9.  
  10.     This text is about the rather old widely spread 'Zebedee Intermud',
  11.     which is also called 'Intermud 2' altough it differs quite a lot
  12.     from the real Intermud 2 protocol.
  13.  
  14.     Full information on the newer Intermud 3 could be found on the
  15.     web at http://www.imaginary.com/protocols/intermud3.html so there
  16.     is no discussion here - the following is just about Zebedee Intermud
  17.     (aka Intermud 2).
  18.  
  19.     Zebedee Intermud communication is handled by the /secure/inetd
  20.     object, originally written by Nostradamus for Zebedee with some
  21.     extensions that are discussed in inetd(C). How the data is
  22.     actually sent across the network is described in intermud.basic(C).
  23.  
  24. SERVICES
  25.     Note that the fields "NAME" and "UDP_PORT" should be present in
  26.     every message. Very common are the fields "ID" (used whenever an
  27.     reply is expected) and "SND" (the sender: he should receive the
  28.     reply). These fields will not be mentioned in the list below. 
  29.  
  30.     Request types are listed on the leftmost row (e.g. "REQ=channel"),
  31.     associated header are listed indented.
  32.  
  33.     "channel"
  34.              The channel-request is used for sending a message on any
  35.         channel. The "CMD" field is optional and may be omitted for
  36.         normal messages. Note that you should not send an history or
  37.         list request to _all_ known muds! 
  38.  
  39.              "CHANNEL"
  40.             The channel on which a message is send (the standard
  41.             channels are "intermud", "intercode", "interadm", "d-chat",
  42.             "d-code" and "d-adm"; on the d-channels German is spoken) 
  43.  
  44.         "DATA"
  45.             The message to be send (not used with history/list request) 
  46.  
  47.         "CMD"
  48.             The body of this header may be:
  49.             ""        for normal intermud messages, 
  50.             "emote"   if the message is an emote/gemote, 
  51.             "history" for an history request: the last 20 lines of
  52.                       this channel will be shown. 
  53.             "list"    to list all remote users listening to this channel 
  54.  
  55.         "EMOTE"     (optional)
  56.             The body is 1 if the message is an emote.
  57.             The body is 2 if the message is a gemote.
  58.  
  59.     "finger"
  60.         Retreive information about a player or creator on a remote mud. 
  61.  
  62.         "DATA"
  63.             The player of whom information is requested 
  64.  
  65.     "locate"
  66.         Check whether a certain player is logged on at a remote mud.
  67.             This request is usually send to all known muds at the same time. 
  68.  
  69.         "USER"
  70.             Name of the person who requests the information. 
  71.  
  72.         "VBS"
  73.             The verbose option has only two pre-defined values: 
  74.             "1" Even report when the result was negative 
  75.             "2" Don't do timeouts, but keep waiting 
  76.  
  77.         "FND"
  78.             The found option is only used in the reply and it's value
  79.             is either 1 (success) or 0 (failure). The absence of a
  80.             found parameter indicates failure as well. 
  81.  
  82.         "DATA"
  83.             The player to find.
  84.  
  85.     "man"
  86.         Retreive a manual page from a remote mud. Many muds don't
  87.         support this feature... 
  88.  
  89.         "DATA"
  90.             The name of the requested manual page 
  91.  
  92.     "mail"
  93.         An extension to the standard protocol, by Alvin@Sushi. This is
  94.         used to send mails from one mud to another. 
  95.  
  96.         "udpm_status"
  97.             This field should only be used in the reply and indicates
  98.             how mail is handled. Currently there are four pre-defined
  99.             values for the status field: 
  100.             0 time out 
  101.             1 delivered ok 
  102.             2 unknown player 
  103.             3 in spool (will be delivered later) 
  104.  
  105.         "udpm_writer"
  106.             Name of the person who wrote this mail 
  107.  
  108.         "udpm_spool_name"
  109.             Should be returned as sent, this value is used to remove
  110.             the mail from the spool directory after it has been
  111.             delivered (or refused) 
  112.  
  113.         "udpm_subject"
  114.             Subject of the mail message 
  115.  
  116.         "DATA"
  117.             The body of the mail (the actual message) 
  118.  
  119.     "ping"
  120.         A ping request has only the standard fields, the reply is
  121.         usually a short string like " is alive." 
  122.  
  123.     "query"
  124.         Get standard information about another mud. This is the only
  125.         command of which the reply may not include a load of rubbish,
  126.         but should only hold the requested information, so that it can
  127.         be parsed by the server. 
  128.  
  129.         "DATA"
  130.             The following queries are pretty much standard: 
  131.             "commands" List all commands that are supported by the inetd 
  132.             "email"    The email-address of the mud administrator(s) 
  133.             "hosts"    A listing of all hosts in a special format [t.b.d.] 
  134.             "inetd"    The version number of the inetd used 
  135.             "list"     The list of all items which can be queried 
  136.             "info"     A short human-readable string with practically
  137.                        "query" information 
  138.             "mud_port" The portnumber that players connect to on login 
  139.             "time"     The local time for this mud 
  140.             "users"    A list of the people that are active in this mud 
  141.             "version"  The version of the mud-driver (and library) 
  142.             "www"      The URL of the mud's web page (e.g.
  143.                        http://mud.stack.nl/) 
  144.  
  145.     "reply"
  146.         This request method is used for _all_ replies. 
  147.  
  148.         "DATA"
  149.             A human-readable string, containing the reply to a given query 
  150.  
  151.         "RCPNT"
  152.             The same name as in the "SND" field or the query; Usually
  153.             this is the name of the player who initiated the query 
  154.  
  155.         "QUERY"
  156.             This field is only used in a response to a "query" request
  157.             and should be equal to the "DATA" field of that request 
  158.  
  159.         "VBS"
  160.             This field is only used in a response to a "locate" request
  161.             and should be equal to the "VBS" field of that request 
  162.  
  163.         "FND"
  164.             This field is only used in a response to a "locate" request
  165.             and should be 1 if the player was located and 0 otherwise 
  166.  
  167.     "tell"
  168.         Say something to a player on another mud. 
  169.  
  170.         "RCPNT"
  171.             Name of the player to whom you are talking 
  172.  
  173.         "DATA"
  174.             Whatever you wish to say to this person 
  175.  
  176.     "who"
  177.         List the people that are active on a remote mud. The anwer
  178.         usually contains some active information about the players,
  179.         like titles, levels or age. 
  180.  
  181.         "DATA"
  182.             Not supported by many muds. Introduced August 1997.
  183.             Additional switch(es) (blanc separated) that change the
  184.             appearence of the resulting list. The switches normally
  185.             resemble the switches used inside of that mud for the 'who'
  186.             command.  Typical values include:
  187.                 "short" "s" "-short" "-s" "kurz":
  188.                 Return a concise listing.
  189.             "alpha" "a" "alphabetisch" "-alpha" "-a"
  190.                 Sort the players alphabetically.
  191.  
  192. AUTHOR
  193.     Information taken from Outerspaces documentation to be found 
  194.     on http://mud.stack.nl/intermud/
  195.  
  196. SEE ALSO
  197.     inetd(C), intermud.basic(C), imp(C)
  198.